Computing devices may have different capabilities and features based on the applications installed in their memory. The applications may be pre-installed to a computing device before purchase by a customer or installed after purchase by a customer or service technician via a storage media, such as a magnetic or optical disk. For computing devices that communicate with a computer network, applications may be installed after a customer or service technician downloads the applications to the computing device.
Installations of applications and updates on client devices present other issues that are not a concern for wired devices. Users of client devices frequently need access to a variety of information, but such information is not as readily available as wired connections due to the limited bandwidth of wireless connections. Also, the traffic experienced by a client device should be minimized in order to minimize power drain on the device's power source. Thus, communications are challenged to maximize the quality of information provided to client devices while minimizing the traffic imposed on the wireless connections to the devices.
A communication that utilizes a large number of applications must have the capability of managing the applications efficiently and proficiently. Two of the more important functions of these systems are client provisioning and device management. Generally, these functions operate independently (with the exception of the WAP profile used in SyncML device management bootstrapping). On the other hand, there are advantages for client provisioning and device management to converge. As application data protocols, both functions are typically generic and, thus, they are quite similar. The major difference between client provisioning and device management is at the level of transport protocols, where client provisioning is confined to a certain type. Thus, the amount and complexity of data that can be provisioned is limited.
Also, other nondevice management agents (e.g. software applications) in addition to client provisioning applications are also used on mobile client devices. For example, device configuration agents typically use different paths and mechanisms to access (e.g. read or write) device management data that is stored in varying locations and different databases leading to complexities and inconsistencies. The open mobile alliance (OMA) device management standard employs application level protocol (syncML DM), with transport protocol bindings (WAP, HTTP, OBEX) and a meta-data model called a device management tree (DMT) and also a small data model that maps some basic device configuration information on to the device management tree. However, the device management tree is designed to be used only with the device management user agent. At the same time other device management protocols and agents may exist on the same device and store and read data, such as client provisioning agents, device setting applications that may set for example the colors of a user interface, and other applications.
For example, FIG. 6 illustrates an example of a prior art device management and provisioning architecture. A wireless client device 600 may be in wireless communication with one or more servers such as an OMA DM server 200, an OMA client provisioning server 204, and other device management servers that may be built according to various other standards shown as server 608. The wireless client device 600 includes an OMA DM agent 208 which communicates with a device management tree 226 (DMT) through a device management engine 222 and communication link 224 (e.g., program calls). The device management tree 226 is a hierarchical metadata structure that stores data such as device management data in a device management data store 614 through a communication link 610. In addition, nondevice management applications or agents such as an OMA CP agent 210 may also store for example provisioning data in the data store 614 but in a separate database or using metadata models different from the DMT meta-data model and through another communication path 621. Similarly a setting application or agent 618 may store device or graphic user interface settings or other data in the DM data store 614 through a communication link 622 but bypassing the DM engine 222. One or more configurable applications or agents 619 may read data from the DM store 614 through yet a different communication path 624. The DM data store may include various data (in databases if desired) such as but not limited to connectivity profiles, subscriber identity module (SIM) data and a set of parameters that reflect the dynamic state of the device referred to as “device readings” information.
As such, multiple agents may bypass the DMT 226 and store data in one more different databases and with different formatting. Hence, the data may not be synchronized and may be corrupted because there is no locking built in (e.g. multiple writes could potentially occur). In addition, the DMT controls the storage of data in a hierarchical fashion and is not typically used in the course of running an application. Also, device settings are typically stored in proprietary locations and other applications may not know where the device settings are located. In addition, other agents may store data in the DM data store 614 but not in an understood manner so that the data cannot be found by other agents. Conventional systems typically require that only the DM agent can utilize the DMT 226. Accordingly, there is a need to provide an apparatus and methods that overcome one or more of the above drawbacks.